In the field of cellular communication systems, for example cellular communication systems conforming to 3rd Generation Partnership Project (3GPP) specifications, typically the network controls the mobility of a mobile communication unit (or user equipment (UE) in 3GPP parlance) that is in a connected mode (or to be precise in 3GPP terms in an RRC_CONNECTED state). For example, the network decides with which cell the UE maintains a radio connection (also referred to as the serving cell). The network applies the handover procedure to move the UE from one cell, namely the serving cell, to another cell, referred to as the target cell. The network decides the cell, as well as the Radio Access Technology (RAT) in some circumstance, that the UE should connect to typically based on radio quality. However, the network may also take into account other factors, such as cell load, UE capabilities, the type of bearers that are (being) established, etc. To assist the handover decision process, the network normally configures the UE to perform measurements on a serving frequency for its current serving cell (referred to as intra-frequency measurements), on other frequencies used by the Radio Access Technology for that network (referred to as inter-frequency measurements) and/or on frequencies used by other Radio Access Technologies (referred to as inter-RAT measurements).
FIG. 1 illustrates an example of a typical overall handover procedure 100 for a UE 105. More specifically FIG. 1 illustrates an Intra-MME (Mobility Management Entity)/Serving Gateway handover as defined in the 3GPP Technical Specification (TS) 36.300.
Once a decision has been made to perform a handover, the handover procedure 100 starts with a preparation stage 110 comprising a source eNB 102 (enhanced NodeB) forwarding a HANDOVER REQUEST message 112, as defined in 3GPP TS 36.413, to a target eNB 104, the HANDOVER REQUEST message 112 comprising handover preparation information needed to prepare for the handover. The HANDOVER REQUEST message 112 carries the handover preparation information within a HandoverPreparationInformation message, defined in 3GPP TS 36.331, and includes:                radio access capabilities for the UE;        a current radio access (e.g. access stratum, AS) configuration;        RRM (Radio Resource Management) configuration, such as information kept only by the eNB that is used primarily for Radio Resource Management (where usage of such RRM configuration information is eNB implementation-dependent); and        radio access (AS) context, i.e. information kept only by the eNB (i.e. information that is not exchanged across the radio interface), such as information needed to perform RRC (Radio Resource Control) connection re-establishment.        
If the target eNB 104 accepts the handover, it reserves the radio resources and decides on the details of the radio access configuration to be used by the UE 105 in the target cell. This radio access configuration is returned to the source eNB 102 within a HANDOVER REQUEST ACK message 114, as defined in 3GPP TS 36.413. This HANDOVER REQUEST ACK message 114 carries the radio access configuration within a HandoverCommand message, that is defined in 3GPP TS 36.331. The HandoverCommand message again carries an RRCConnectionReconfiguration message, as defined in 3GPP TS 36.331. When used to perform a handover within, say, E-UTRA, this message includes the radio access configuration to be used in the target cell, such as:                the measurement configuration, expressed by way of a ‘delta’ compared to the configuration used in the source cell (the delta indicating configuration changes, as opposed to complete configuration information, in order to reduce the size of the message);        the mobility control information, which specifies the target cell identity (by means of a cell identity) and some characteristics (such as a frequency, a bandwidth and additional spectrum emission information; only if different from what is used in the source cell, i.e. delta signaling information is provided), the new radio access identity to be used in the target cell, the cell-specific radio resource configuration (common for all UEs), dedicated resources used for initial access in the target cell and a timer to limit the duration that the UE tries connecting to the target cell;        the UE-specific radio resource configuration (i.e. the dedicated radio configuration), also expressed as a delta, compared to the configuration used in the source cell; and        the security configuration, i.e. the algorithms, if different from the ones used in the source cell (delta), as well as parameters affecting the derivation of radio access security keys (i.e. an indication whether a new base key is to be used and a counter that is incremented upon every handover).        
After the preparation stage 110, handover execution is performed as illustrated generally at 120, whereby the source eNB 102 proceeds with the handover, which includes the source eNB 102 transparently forwarding a RRCConnectionReconfiguration message 122 to the UE 105 (i.e. it does not change the message contents; the source eNB does however perform integrity protection and ciphering of the message), and the UE 105 attempting to connect to the target cell (steps 124, 126), and returning a RRCConnectionReconfigurationComplete message 128, as defined in 3GPP TS 36.331.
The signaling used upon handover, as defined in 3GPP TS 36.331 to a large extent applies delta signaling for the various parameters, or fields in 3GPP parlance, whereby the radio access network (Evolved Universal Terrestrial Radio Access Network? EUTRAN in the case of 3GPP TS 36.331) only signals values that change from those used in the source cell. 3GPP TS 36.331 specifies the signaling (the Protocol Data Unit content) by means of ASN.1. Fields for which delta signaling applies are defined as optional, so they may be absent, in combination with a need code of ‘ON’ whereby in case of absence the receiver takes no action with respect to such fields, and where applicable continues to use the existing value (and/or associated functionality). FIG. 2 illustrates an example 200 of a message definition for RRCConnectionReconfiguration messages in accordance with 3GPP TS 36.331. For the example illustrated in FIG. 2, the field measConfig 210 is defined as being OPTIONAL (at 220), with a need code of ‘ON’ (at 230). It should be noted that whilst the example illustrated in FIG. 2 only shows the fields present at the message level, similar considerations with regard to fields being defined as ‘optional’ with need codes of ‘ON’ apply at other levels. For example, FIG. 3 illustrates an example 300 of a definition for a RadioResourceConfigDedicated information element (IE) (in accordance with 3GPP TS 36.331) comprising several optional fields with need codes set to ‘ON’.
Whilst the use of delta signaling in this manner enables a significant reduction in the signaling overhead required when a handover is performed, it also creates issues with respect to backward compatibility when a target eNB is arranged to support an earlier release of the radio access protocols than a version supported by both the serving eNB and UE.
For optional fields with a need code of ‘ON’, explicit signaling is required to deactivate functionality associated with that field, such as for backward compatibility purposes, as applies when the target eNB does support the concerned functionality. For example, in the case where, say, the sps-Config field 310 illustrated in FIG. 3 is absent in a RadioResourceConfigDedicated identity element (IE), the UE will continue to use previously configured values. Accordingly, in order to deactivate previously active functionality, it is necessary to include the appropriate fields in a manner that is suitable to ‘clear’ the previously configured values.
The RRC protocol defined in 3GPP TS 36.331 includes different kinds of protocol extensions that may be added for later versions of the specifications, of which there are two prime categories: non-critical extensions (NCE) and critical extensions (CE). It has been agreed that the non-critical extension mechanism is the primary extension mechanism, since it just adds on to the existing signaling. This, for example, means that when a message is received that includes non-critical extensions that are not comprehended by the receiver, the message may be processed as if the extensions were not present. In contrast, a message that includes critical extensions that are not comprehended is completely ignored by the receiver. Such critical and non-critical extensions are provided in various different manners:                defining new message types;        defining a new message version;        adding an optional open SEQUENCE at the end of a message or within a size-delimited container e.g. a bit string;        extending the values of a field of ENUMERATED type by using a value previously defined as spare or by adding a new value after an extension marker;        extending the values of a field of CHOICE type by using a value previously defined as spare or by adding a new value after an extension marker;        extending a field of SEQUENCE type by adding new fields after an extension marker;        
etc.